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(54) Techniques for implementing pluggable virtual machines 



(57) Techniques for developing and exchanging vir- 
tual machine implementations and/or support library im- 
plementations are described. In one embodiment, the 
virtual machine design specifies a set of functions for 
executing all or substantially all support library opera- 
tions that are dependent on ' the implementation of the 
virtual machine. When a developer desires to substitute 
one virtual machine implementation for another, the de- 



veloper is able to basically "plug-in" the second virtual 
machine implementation with minimal impact on the 
support libraries since both virtual machine implemen- 
tations proVitte implementations for the set of specified > 
functions that are dependent on the implementation of 
the 1 respective virtual machine. Conversely, different 
support libraries may be utilized in conjunction with a 
particular virtual machine implementation. 
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Description 

BACKGROUND OF THE INVENTION 

[0001] The present invention relates generally to 
techniques for developing and delivering virtual ma- 
chine implementations. More specifically, the invention 
relates to techniques for creating virtual machine imple- 
mentations that may be exchanged without requiring 
modification of the supporting libraries. 
[0002] The Java™ programming language is an ob- 
ject-based high level programming language developed 
by Sun Microsystems, Inc. of Palo Alto, California, and 
is designed to be portable enough to be executed on a 
wide range of computers ranging from small devices (e. 
g., pagers, cell phones and smart cards) up to super- 
computers. Computer programs written in the Java pro- 
gramming language (and other languages) may be 
compiled into Java virtual machine instructions for exe- 
cution by a Java virtual machine implementation. In the 
abstract, a virtual machine interprets virtual machine in- 
structions. That is, the virtual machine decodes and ex- 
ecutes the virtual machine instructions. Thus, the Java 
virtual machine interprets Java virtual machine instruc- 
tions. 

[0003] The Java virtual machine is commonly imple- 
mented in software by means of an interpreter for the 
Java virtual machine instruction set, but in general may 
be software, hardware, or both. Conventional virtual ma- 
chine interpreters decode and execute the virtual ma- 
chine instructions of an interpreted program one instruc- 
tion at a time during execution, e.g., "at runtime," which 
^is in contrast to compilers that decode source code into 
native machine instructions prior to execution, e.g., "at 
compile time," so that decoding is not performed during 
execution. Typically, the Java virtual machine imple- 
mentation and support libraries, which together consti- 
tute the Java™ runtime environment, will be written at 
least in part in a programming language other than the 
Java programming language (e.g., the C++ program- 
ming language). 

[0004] Computer programs in the Java programming 
language are arranged in one or more classes or inter- 
faces (referred to herein jointly as classes). Such pro- 
grams are generally platform, i.e., hardware and oper- 
ating system, independent. As such, these computer 
programs may be executed, unmodified, on any com- 
puter that is able to run an implementation of the Java™ 
runtime environment. A class written in the Java pro- 
gramming language is compiled to a particular binary 
format called the "class file format" that includes Java 
virtual machine instructions for the methods of a single 
class. In addition to the Java virtual machine instructions 
for the methods of a class, the class file format includes 
a symbol table as well as other ancillary information as- 
sociated with the class. 

[0005] A conceptual view of a conventional imple- 
mentation of the Java runtime environment is shown in 



FIG. 5. As seen therein, the Java runtime environment 
251 includes support libraries 253 and executable pro- 
gram 257 incorporating a Java virtual machine imple- 
mentation 255. Support libraries 253 are also known as 

5 built-in or standard class libraries. Support libraries 253 
include Java methods that may be implemented through 
the use of native functions. Such native functions may 
be delivered, in addition to Java virtual machine imple- 
mentation 255, as part of executable program 257. The 

10 native functions in executable program 257 typically in- 
clude functions for controlling the virtual machine and 
for providing platform specific functions like I/O, graph- 
ical windowing, networking, and the like. It should be ap- 
preciated that the native functions may be written in any 

15 number of different languages and are typically written 
in a language other than the Java programming lan- 
guage. 

[0006] Java virtual machine implementation 255 also 
includes a class loader and a verifier. There is typically 

20 no clear interface between the class loader or class ver- 
ifier portions of a Java virtual machine implementation 
and the remainder of that virtual machine implementa- 
tion. Similarly, there is typically no clear interface be- 
tween the native functions and the virtual machine im- 

25 plementation because the various components of the 
Java runtime environment may be designed at the same 
time. Accordingly, the class loader, verifier, and native 
functions may be written with assumptions about the 
Java virtual machine implementation. For example, they 

30 ; may be written to utilize specific data structures used 
within the Java virtual machine implementation. If a de- 
* * yeloper desires to change the Java virtual machine im- 

• - ^plementation; a substantial amount of time may be re- 
quired to rewrite or modify the class loader, verifier, and 

35 native functions to work with the new Java virtual ma- 
chine implementation. 

[0007] The support libraries 253 may also include ad- 
ditional native functions or other methods that are at 
least partially dependent on the specific implementation 

40 of the Java virtual machine utilized in the Java runtime 
environment. For example, many operations that the 
support libraries perform require access to data struc- 
tures managed by the Java virtual machine or services 
provided by the Java virtual machine (e.g., threads). In 

45 conventional implementations this significantly limits the 
modularity of the support libraries since any class library 
that includes an implementation dependent function 
would potentially have to be rewritten or modified to ac- 
commodate a new Java virtual machine implementa- 

50 tion. 

[0008] It view of the foregoing, it would generally be 
desirable to provide a modular runtime environment ar- 
chitecture where the functionality provided by the sup- 
port libraries may be shared by multiple virtual machine 
55 implementations. It would also be desirable to provide 
innovative techniques of developing and delivering vir- 
tual machine implementations that would allow virtual 
machines to be exchanged with essentially no impact 
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on the support libraries. Conversely, it would be desira- 
ble to facilitate the exchange of support library imple- 
mentations with essentially no impact on the virtual ma- 
chine implementations. 

SUMMARY OF THE INVENTION 

[0009] In general, embodiments of the present inven- 
tion provide innovative techniques for developing and 
exchanging virtual machine implementations and/or 
support library implementations. As an example, in one 
embodiment of the invention, the virtual machine design 
specifies a set of functions for executing all or substan- 
tially all support library operations that are dependent 
on the implementation of the virtual machine. When a 
developer desires to substitute one virtual machine im- 
plementation for another, the developer is able to basi- 
cally "plug-in" the second virtual machine implementa- 
tion with minimal impact on the support libraries since 
both virtual machine implementations provide imple- 
mentations for the set of specified functions that are de- 
pendent on the implementation of the respective virtual 
machine. This allows the developer great flexibility in ex- 
changing the virtual machine implementation. Several 
embodiments of the invention are described below. 
[0010] In one embodiment, a method for developing 
virtual machine implementations includes providing an 
interface as part of the virtual machine design that spec- 
ifies functions that may be called by functions which are 
part of the support library implementations. The set of 
functions that essentially make up the; interface execute % 
all or substantially all operations utilized by the support 
libraries that are dependent on the implementation- of 
the virtual machine. The set of functions may include 
operations that control a virtual machine implementa- 
tion, access data managed by the virtual machine, and 
perform input/output (I/O) operations. 
[0011] As the interface specifying all or substantially 
all of the operations utilized by the support libraries that 
are dependent on the implementation of the virtual ma- 
chine has been specified in the design of the virtual ma- 
chine, the same implementation of the support libraries 
may be readily utilized by any of several implementa- 
tions of the virtual machine. Accordingly, one of two vir- 
tual machine implementations may be easily replaced 
with the other. In other words, the virtual machine imple- 
mentations may be considered to be "pluggable," e.g., 
interchangeable. In preferred embodiments, the virtual 
machine is a Java virtual machine and the interface is 
a binary interface, i.e., the virtual machine implementa- 
tions are "binary pluggable." 

[0012] In still another embodiment, a method for de- 
veloping virtual machine implementations includes pro- 
viding an interface as part of a support library design 
that specifies functions that may be called by functions 
which are part of virtual machine implementations. The 
set of functions that effectively make up the interface 
execute operations utilized by the virtual machine im- 



plementation that may be supplied by the support librar- 
ies. The set of functions may include common utilities 
or critical code that would preferably not be duplicated. 
[001 3] Since the interface specifying operations used 

5 by a virtual machine implementation that are supplied 
by the support libraries have been specified in the de- 
sign of the support libraries, the same implementation 
of a virtual machine may be readily utilized by any of 
several implementations of the support libraries. As 

10 such, one of two support library implementations may 
be easily replaced with the other, i.e., the support library 
implementations are "pluggable." In some embodi- 
ments, the support libraries are those of a Java runtime 
environment and the interface is a binary interface, i.e., 

15 the support library implementations are "binary plugga- 
ble." 

[0014] Other features and advantages of the inven- 
tion will become readily apparent upon review of the fol- 
lowing detailed description in association with the ac- 
20 companying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0015] The present invention, in specific embodi- 
25 ments, may be understood by reference to the following 
description taken in conjunction with the accompanying 
drawings in which: 

[0016] 1 FIG. 1 illustrates an example of a computer 
system that may be utilized to execute the software of 
30 an embodiment of the invention. 

. [0017] ' FIG. 2:showsasystem block diagram of the 
.computer system of FIG. 1. 

: [00 18] "-FIG. 3 shows how a Java source code program 
is executed. 

35 [0019] FIG. 4 shows the components of a Java virtual 
machine implementation. 

[0020] FIG. 5 illustrates a conventional Java virtual 
machine implementation. 

[0021] FIG. 6 illustrates an embodiment of a virtual 
40 machine implementation in accordance with an embod- 
iment of the present invention. 
[0022] FIG. 7 illustrates conceptually how one Java 
virtual machine implementation may be exchanged for 
another in accordance with an embodiment of the 
45 present invention. 

[0023] FIG. 8 illustrates conceptually how one library 
that may be used with a Java virtual machine implemen- 
tation may be exchanged for another library in accord- 
ance with an embodiment of the present invention. 

50 

DETAILED DESCRIPTION OF PREFERRED 
EMBODIMENTS 

Definitions 

55 

[0024] Machine instruction - An instruction that directs 
a computer architecture to perform an operation; an in- 
struction that is specified by an operation code (opcode) 
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and optionally one or more operands. 
[0025] Virtual machine instruction - A machine in- 
struction for an abstract computer architecture, typically 
implemented by emulation or interpretation by a soft- 
ware program. 

[0026] Native machine instruction - A machine in- 
struction that is designed for a concrete computer archi- 
tecture or microprocessor. 

[0027] Class - An object-oriented data type that de- 
fines objects that share the same characteristics, typi- 
cally including both data and methods that operate on 
the data. 

[0028] Object (or class instance) - An instantiation of 
a class. 

[0029] Function - A software routine (also called a 
subroutine, procedure, member function, and method). 
[0030] Native functions - Functions that are written in 
a programming language other than the Java program- 
ming language 

[0031] Native methods - Methods that are declared in 
the Java programming language but that are implement- 
ed through the use of native functions. 

Overview 

[0032] In the description that follows, the present in- 
vention will at times be described in reference to pre- 
ferred embodiments directed to the Java virtual machine 
and Java virtual machine implementations. In particular, 
examples will be described in which Java virtual ma- 
chine implementations are developed or exchanged: 
.However, the invention is -not limited to any particular 
virtual machine, virtual machine implementation, pro- 
gramming language, computer architecture, or specific 
implementation. Specifically, virtual machines and virtu- 
al machine implementations are not necessarily Java 
virtual machines and Java virtual machine implementa- 
tions. Therefore, the description of the embodiments 
that follow is for purposes of illustration and not limita- 
tion. 

[0033] FIG. 1 illustrates an example of a computer 
system that may be used to execute the software of an 
embodiment of the invention. FIG. 1 shows a computer 
system 1 that includes a display 3, screen 5, cabinet 7, 
keyboard 9, and mouse 11. Mouse 11 may have one or 
more buttons for interacting with a graphical user inter- 
face. Cabinet 7 houses a CD-ROM drive 13, system 
memory and a hard drive which may be utilized to store 
and retrieve software programs incorporating computer 
code that implements the invention, data for use with 
the invention, and the like. Although the CD-ROM 15 is 
shown as an exemplary computer readable storage me- 
dium, other computer readable storage media including 
floppy disk, tape, flash memory, system memory, and 
hard drive may be utilized. Additionally, a data signal 
embodied in a carrier wave (e.g., in a network including 
the Internet) may be the computer readable storage me- 
dium. 



[0034] FIG. 2 shows a system block diagram of com- 
puter system 1 used to execute the software of an em- 
bodiment of the invention. As in FIG. 1, computer sys- 
tem 1 includes monitor 3 and keyboard 9, and mouse 
5 11. Computer system 1 further includes subsystems 
such as a central processor 51, system memory 53, 
fixed storage 55, removable storage 57 (e.g., CD-ROM 
drive), display adapter 59, sound card 61, speakers 63, 
and network interface 65. Other computer systems suit- 
to able for use with the invention may include additional or 
fewer subsystems. For example, another computer sys- 
tem could include more than one processor 51 (i.e., a 
multi-processor system), or a cache memory. 
[0035] The system bus architecture of computer sys- 
15 tern 1 is represented by arrows 67. However, these ar- 
rows are illustrative of any interconnection scheme serv- 
ing to link the subsystems. For example, a local bus 
could be utilized to connect the central processor to the 
system memory and display adapter. Computer system 
20 1 shown in FIG. 2 is but an example of a computer sys- 
tem suitable for use with the invention. Other computer 
architectures having different configurations of subsys- 
tems may also be utilized. 

[0036] Typically, computer programs written in the 

25 Java programming language are compiled into Java vir- 
tual machine instructions that are then executed by a 
Java virtual machine implementation. The virtual ma- 
chine instructions are stored in a binary format known 
as the "class file format" that is input into the Java virtual 

30 machine implementation for execution. FIG. 3 shows a 
progression of- as imp le piece of source code through 

, * execution by .a Java virtual/machine implementation. 
[0037] ^Source'code 101 includes the- classic "Hello 
World" program written in the Java programming lan- 

35 guage. The source code is then input into a compiler 
103 for the Java programming language that compiles 
the source code into Java virtual machine instructions. 
The Java™ compiler outputs a class file 105 that in- 
cludes the Java virtual machine instructions corre- 

40 sponding to source code 101 . The Java virtual machine 
instructions will be executed by a Java virtual machine 
implementation. 

[0038] Class file 105 is input into a Java virtual ma- 
chine implementation 107. Java virtual machine imple- 

45 mentation 107 decodes and executes the Java virtual 
machine instructions in the class file 105. Java virtual 
machine implementation 107 is typically an interpreter 
or a software emulator but may use other implementa- 
tion techniques. 

so [0039] FIG. 4 shows the components of a represent- 
ative virtual machine implementation 201. The illustrat- 
ed embodiment is a Java virtual machine implementa- 
tion, although it could represent other virtual machine 
implementations as well. A variety of inputs may be 

55 made to the virtual machine implementation 201. By 
way of example, these inputs may take the form of ap- 
plication classes 203, library classes 205 and native 
functions 207. The application classes 203 typically con- 
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stitute programs to be executed by the virtual machine 
implementation that have been compiled to virtual ma- 
chine instructions. The library classes 205 are classes 
that provide a variety of services to the virtual machine 
implementation that may be useful or necessary to op- 
erate the virtual machine implementation and/or support 
its execution of received programs. The native functions 
207 are functions necessary to support the library class- 
es 205. The native functions are typically stored in dy- 
namic-link libraries (DLLs) or shared libraries in a plat- 
form specific way. Conceptually, the library classes 205 
and native functions 207 together are referred to herein 
as the class libraries 204. 

[0040] The virtual machine implementation 201 may 
also interface with shared virtual machine utilities 210 
and an operating system 209. The operating system 
may handle a number of primitive functions for the virtual 
machine implementation 201, as for example basic I/O 
functions. As will be described in more detail below, the 
shared virtual machine utilities 210 are dedicated func- 
tions that a virtual machine implementation 201 can 
count on to be present in the runtime environment to 
provide specific services. 

[0041] The virtual machine implementation itself in- 
cludes a dynamic class loader and verifier 211 , a native 
function loader 215, memory 213 and execution engine 
217. The dynamic class loader and verifier 211 loads 
application classes 203 and library classes 205 via op- 
erating system 209 into a memory 213. Additionally, the" 

• dynamic class loader and verifier 211 verifies the cor^ 
rectness of the virtual machine instructions in received^ 

v application classes 203 and reports any errors that are> 

-detected during the verification. 
[0042] A native function loader 215 loads in native 
functions 207 via operating system 209 into the virtual 
machine implementation and stores the loaded native 
functions 207 in memory 213. As shown, memory 213 
may include a class and method area for classes and a 
native function area for native functions. The class and 
method area in memory 213 may be stored in a gar- 
bage-collected heap. As new objects are created, they 
are stored in the garbage-collected heap. The virtual 
machine implementation, not the application, is respon- 
sible for reclaiming memory in the garbage-collected 
heap when space is no longer being utilized. 
[0043] At the heart of the Java virtual machine imple- 
mentation shown in FIG. 4 is an execution engine 217. 
The execution engine carries out the instructions stored 
in memory 213 and may be implemented in software, 
hardware or a combination of the two. The execution 
engine supports programs written using the virtual ma- 
chine instruction set and conceptually there may be mul- 
tiple execution engines running concurrently, one for 
each thread of control. The operation of virtual ma- 
chines, and more particularly, the Java virtual machine 
is described in more detail in The Java Virtual Machine 
Specification by Tim Lindholm and Frank Yellin (ISBN 
0-201 -63452-X), which is incorporated herein by refer- 



ence. 

[0044] Referring next to FIG. 6 one embodiment of a 
runtime environment in accordance with the present in- 
vention will be described. The invention will be de- 

5 scribed in the context of a Java runtime environment, 
although it should be appreciated that the underlying 
ideas are not so limited. As shown, the runtime environ- 
ment 301 includes support libraries 303 and a virtual 
machine implementation 305. The runtime environment 

10 also includes a runtime API 304 that is accessible to ex- 
ternal objects. 

[0045] Support libraries 303 conceptually include 
both class libraries 308 and shared virtual machine util- 
ities 310. The class libraries 308 generally include meth- 

1$ ods and native functions used to implement native meth- 
ods. In a Java runtime environment, the methods are 
generally written in the Java programming language. 
Native functions included in support libraries 303 typi- 
cally provide platform specific functions like I/O, graph- 

20 ical windowing, networking, and the like. In a Java runt- 
ime environment, the native functions may be written in 
any number of different languages and typically are writ- 
ten in a language other than the Java programming lan- 
guage. In the embodiment shown in Fig. 6, the class li- 

25 braries 308 include Abstract Windowing Toolkit (AWT) 
classes 351, networking classes 353, I/O classes 355, 
reflection classes 357 which include functions that pro- 
vide introspection service for classes, and lang classes 
■ 359 which provide primitive utilities such, as strings, 

30 threads and hash tables. •;. 

. , [0046] The shared.virtual machineutilities.31 0 are virr 
tual machine functions that any virtual! machine imple- 
" mentation may unambiguously relyon^tobe^presentMn 1 ' 
the support libraries 303 and generally perform services 

35 that may be required by a virtual machine implementa- 
tion. By way of example, the shared virtual machine util- 
ities may include a verifier 312 capable of verifying the 
correctness of the class. As will be appreciated by those 
skilled in the art, a verifier can be extremely difficult to 

40 write securely and thus by effectively separating the ver- 
ifier from the virtual machine implementation, it is easier 
to create a different virtual machine implementation 
since the verifier does not need to be rewritten as well. 
The shared virtual machine utilities 310 may also in- 

45 elude class file parser 314 which is capable of parsing 
received classes. Like the verifier 312, the class file 
parser 314 provides an important service to the virtual 
machine implementation, but can be difficult to write and 
thus, by effectively separating the class file parser from 

so the virtual machine implementation, it is easier to create 
a different virtual machine implementation. 
[0047] In contrast to the arrangement in the back- 
ground section with reference to FIG. 5, the virtual ma- 
chine implementation of FIG. 6 includes a virtual ma- 

55 chine binary interface 306 that specifies functions that 
will generally be supplied by the virtual machine imple- 
mentation. Conversely, the shared virtual machine util- 
ities such as the verifier 312 and class file parser 314 
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each include binary library interfaces 315 that may be 
used by the virtual machine to access their functionality. 
By specifying the binary interfaces of the virtual machine 
and specific shared virtual machine utilities 310, a flex- 
ible architecture may be provided which permits virtual 5 
machine implementations to be exchanged without re- 
quiring modification of the supporting libraries. 
[0048] As will be appreciated by those skilled in the 
art, conventional virtual machines are arranged to per- 
form a wide variety of functions and thus a large set of 10 
virtual machine interface functions must be declared to 
define the virtual machine interface 306. In order to 
avoid unnecessary complexity, no effort is made herein 
to identify all of the interface functions that may be ap- 
propriate for a particular virtual machine, however for 15 
the purposes of illustration a few representative func- 
tions will be described below. 

[0049] As wilt be appreciated by those skilled in the 
art, a number of the functions performed by a particular 
virtual machine implementation will be implementation 20 
specific in that some of their operations will be depend- 
ent upon the implementation of the virtual machine. If 
these functions are accessible to the support libraries 
303, then to make virtual machine implementations 
more readily pluggable it is desirable to define the inter- 25 
faces for such functions in manners that are not imple- 
mentation dependent. Thus, the set of virtual machine 
interface, functions preferably execute substantially all 
■ operations that are dependent on the implementation of 1 
the virtual machine. Most preferably, the set of virtual 30 
» machine* interface functions execute all operations that .« j 
♦ are dependent on the implementation of the virtual ma- > 
chine. The set of functions that depend on the imple- 
mentation of the virtual machine may include functions 
that get the values of fields, get the number of methods 35 
within a class, get the signature of a given class, and 
the like. The set of virtual machine interface functions 
may also include functions that control the virtual ma- 
chine. An example of such a function is a virtual machine 
interface function that instructs the virtual machine to 40 
perform garbage collection. 

[0050] By way of example, one potential virtual ma- 
chine interface function is a "Get Class Fields Count" 
function which is arranged to return the number of fields 
declared in a class. Such a function is generally imple- 45 
mented by the virtual machine in some implementation 
specific way since the manner in which the information 
is retrieved will depend at least in part on how the class 
is stored by a particular virtual machine implementation. 
More specifically, each implementation of the virtual ma- 50 
chine may have a different way of representing a class 
in memory. For this reason, the Get Class Field Count 
function may need to know how the class (or objects of 
the class) is stored in memory. Thus, to provide modu- 
larity, the interface to the Get Class Fields Count func- 55 
tion is specified in such a way as to abstract details of 
how a particular virtual machine stores a class so that 
a function calling the Get Class Fields Count function 



does not need to know those details, but only the ab- 
stractions. Thus the interface to the Get Class Fields 
Count function forms part of the virtual machine inter- 
face 306. 

[0051] In conventional Java virtual machine imple- 
mentations, there may not be an equivalent function to 
the "Get Class Fields Count" function declared in the 
virtual machine. This is because the libraries are typi- 
cally written in conjunction with the virtual machine im- 
plementation. However, if a developer desires to ex- 
change the virtual machine implementation (e.g., with 
one that is implemented differently and provides gener- 
ally faster execution), the developer may need to rewrite 
many or all of the library functions that relied on assump- 
tions about the implementation of the Java virtual ma- 
chine. Rewriting library functions is disadvantageous for 
a number of reasons including the inefficiency of rewrit- 
ing the functions, reconciling the different virtual ma- 
chine implementations, and the possibility that the re- 
written functions will have errors and need to be de- 
bugged. 

[0052] Referring in combination to Figs 4 and 6, a use 
of such a function will be described in the context of a 
exemplary situation where the runtime environment 301 
is requested to load an application class 203. As de- 
scribed above, the class loader 211 is part of virtual ma- 
chine implementation 305 and is arranged to make a 
call to the verifier 312 which is part of shared VM utilities 
310 to verify the class as indicated by an arrow 307. The 
verifier 312 ensures that the class satisfies a set of con- 
straints so that the class will not violate the integrity of 
the virtual machine. < ; : ■ ■ : v - j >. . 
[0053] In order for the class to be verified; the- verifier 
function may in turn call a function that gets the number 
of fields for a class, as for example the Get Class Fields 
Count function provided within virtual machine imple- 
mentation 305 which is accessible through the virtual 
machine interface 306. The verifier calls Get Class 
Fields Count function as indicated by an arrow 309 of 
Fig. 6. As described above, the Get Class Fields Count 
function, as well as essentially all other functions that 
execute operations required by the support libraries that 
are dependent on the implementation of the virtual ma- 
chine, is provided as part of the virtual machine imple- 
mentation and are accessible through the virtual ma- 
chine interface 306. Thus, the verifier 312 does not need 
or depend on virtual machine implementation details. 
Rather it relies upon the virtual machine interface 306. 
At the same time, it should be appreciated that the ver- 
ifier 312 may be shared by more than one virtual ma- 
chine implementation. Accordingly, a developer is able 
to encapsulate the implementation-specific details with- 
in the virtual machine. 

[0054] The overall interface between the virtual ma- 
chine implementation 305 and the support libraries 303, 
is a bi-directional interface which generally allows for 
communication between virtual machine implementa- 
tion 305 and support libraries 303. Virtual machine im- 
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plementation 305 typically calls shared virtual machine 
utilities 310 through a utilities interface 315. Conversely, 
support libraries 303 typically call virtual machine imple- 
mentation 305 through virtual machine interface 306, It 
should be appreciated that in many circumstances, the 
interface between virtual machine implementation 305 
and support libraries 303 may operate in a uni-direction- 
al manner. For example, not all calls from virtual ma- 
chine implementation 305 to shared virtual machine util- 
ities 310 will necessarily result in a return call from 
shared virtual machine utilities 310 to virtual machine 
implementation 305, and vice versa. By way of example, 
virtual machine implementation 305 may call a class file 
parser 314 that does not make a return call into virtual 
machine implementation 305. Similarly, a native func- 
tion defined in one of the class libraries 308 may call a 
function defined in the virtual machine interface 306 that 
causes garbage collection to occur. In this situation, the 
garbage collector within the virtual machine implemen- 
tation 305 does not make a return call to support libraries 
303. It is noted that like the Get Class Field Count func- 
tion described above, the function that starts the gar- 
bage collector on the virtual machine is likely to be de- 
pendent on the implementation of the virtual machine. 
[0055] Using the garbage collection example, a Virtu- 
al Machine Garbage Collection function is declared in 
virtual machine implementation 305 and would start the 
garbage collector. Thus, when an application wishes to 
activate garbage collection, the application makes a call 
to a native method in the class libraries 308 which in turn 
calls the VirtualMachine Garbage Collection function to 
start the garbage collector. The garbage collection op- 
eration will: then be performed by a function declared in 
virtual machine implementation 305. Therefore, the im- 
plementation-specific garbage collector start function is 
encapsulated in virtual machine implementation 305 
through virtual machine interface 306. 
[0056] An advantage of the described architecture is 
that a developer (or anyone with the capability) may 
change the virtual machine implementation without a 
major impact to the support libraries. For example, FIG. 
7 illustrates conceptually how one virtual machine im- 
plementation may be exchanged for another. Support 
libraries 453 are shown as described above. A first vir- 
tual machine implementation 455 may be exchanged for 
a second virtual machine implementation 457 by caus- 
ing the support libraries 453 to call the second virtual 
machine implementation in place of the first one, and 
causing the second virtual machine implementation to 
call the support libraries 453. In some embodiments, the 
virtual machine implementations may be delivered as 
DLLs (dynamic link libraries) so a user may simply 
change the DLL that is utilized. The designations of 
"first" and "second" are not intended to imply that the 
invention is limited to virtual machine implementation 
upgrades. The invention may be advantageously ap- 
plied to exchanging virtual machine implementations for 
any number of reasons including the utilization of mul- 



tiple virtual machine implementations. 
[0057] When a virtual machine implementation is ex- 
changed for another, the library functions in support li- 
braries 453 may remain substantially unchanged. In 

5 preferred embodiments, the libraries remain totally un- 
changed. Because the virtual machine design encapsu- 
lates the functions that are dependent on the implemen- 
tation of the virtual machine, the libraries are isolated 
from changes in the virtual machine implementations. 

10 [0058] As described above, one advantage of embod- 
iments of the invention is that a developer may ex- 
change virtual machine implementations without signif- 
icantly impacting the support libraries. Alternatively, a 
developer may exchange support libraries without caus- 
es ing a significant impact on a virtual machine implemen- 
tation which uses the support libraries. In other words, 
one virtual machine implementation may use multiple 
implementations of support libraries. FIG. 8 illustrates 
conceptually how an implementation of a support library 

20 associated with a virtual machine implementation may 
be exchanged for another support library. 
[0059] A first library implementation 503 may be ex- 
changed for a second library implementation 505 by 
causing the virtual machine implementation to call the 

25 second library implementation 505 in place of the first, 
and causing second library implementation to call the 
virtual machine implementation. By way of example, in 
some embodiments, libraries 503, 505 may be delivered 
; as DLLs such that a user may change the DLL that is . 

30 utilized. In other embodiment libraries 503, 505 may be 
■ delivered as compiled code (as for example compiled , 
Java code) or a combination of compiled Java code and* 
■•■ DLLs. " ' f • ■:; 

[0060] While the above is a complete description of 

35 preferred embodiments of the invention, various alter- 
natives, modifications, and equivalents may be used. It 
should be evident that the invention is equally applicable 
by making appropriate modifications to the embodi- 
ments described above. For example, the embodiments 

40 described have been in reference to a Java virtual ma- 
chine, but the principles of the present invention may be 
readily applied to other systems and languages. There- 
fore, the above description should not be taken as lim- 
iting the scope of the invention that is defined by the 

45 metes and bounds of the appended claims along with 
their full scope of equivalents. 



Claims 

50 

1 . A method for developing virtual machine implemen- 
tations, comprising: " 

providing library functions that call functions 
55 declared in a virtual machine; and 

declaring in a first virtual machine implementa- 
tion, a set of functions for executing substan- 
tially all virtual machine operations required by 
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the library functions that are dependent on the 
first virtual machine implementation. 

2. The method of claim 1 , further comprising replacing 
the first virtual machine implementation with a sec- 5 
ond virtual machine implementation, wherein the li- 
brary functions may be readily utilized with the sec- 
ond virtual machine implementation. 

3. The method of claim 1 or 2, wherein at least some 10 
of the library functions are called by the functions 
declared in the first virtual machine implementation. 

4. The method of any of the preceding claims, wherein 
the set of functions includes all operations that are *5 
dependent on the implementation of the first virtual 
machine implementation. 

5. The method of any of the preceding claims, wherein 

the set of functions includes operations that control 20 
the first virtual machine implementation, access da- 
ta and perform input/output (I/O) operations. 

6. The method of any of the preceding claims, wherein 

the first and second virtual machines implementa- 25 
tions are Java virtual machine implementations. 

7. A computer program product for implementing vir- 
tual machines, the computer program product being 
embodied in a computer readable media and com- 

* prising: .7 v 
■i ■> . computer code- that perform the step de- 
. •> scribed in any of the preceding claims. ** 

8. The computer program product of claim 7, wherein 35 
the computer readable medium is selected from the 
group consisting of CD-ROM, floppy disk, tape, 
flash memory, system memory, hard drive, and data 
signal embodied in a carrier wave. 

40 
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public class HelloWorld { 
public static void main (String args[]) { 
System.out.println("Hello World!"); 

} 

} 
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